Configure MTU via peripheral builder#867
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
|
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit bce7bae. Configure here.
| ) | ||
|
|
||
| suspendUntil<State.Connecting.Services>() | ||
| if (desiredMtu != null) requestMtu(desiredMtu) |
There was a problem hiding this comment.
If requestMtu() fails at this point (throwing GattRequestRejectedException), is it cancelling the connection? Shouldn't it be able to continue the connection with the default MTU?
There was a problem hiding this comment.
Yes, it would cancel the connection.
I believe that is desirable though.
The requestMtu is just that: requesting an MTU. Assuming properly behaving firmware, the firmware will respond with the MTU to settle on. Hence why Android 14+ always (no matter what value you specify) requests the max (517) and lets the firmware respond with what it actually supports.
If the MTU request fails, then I'd imagine there is a bigger problem at hand, as the firmware should really always be OK with any MTU request and simply respond with what it supports. My guess is that any failure seen at this stage will be because of a faulty connection or misbehaving firmware.
Core Bluetooth always negotiates an MTU on connection (you can't disable that). I'm guessing (I have not verified though — it would be very difficult to test), that a failure at the time of requesting an MTU, it would also result in either the firmware telling it what MTU it will accept or a loss of connection.
2 participants
Closes #811
Note
Medium Risk
Breaking API removal and new default MTU on every connect change connection timing and permission requirements; write chunk sizing behavior changes on newer Android versions due to the attribute-length cap.
Overview
Android MTU is now configured on the peripheral builder instead of calling
requestMtuduringonServicesDiscoveredor onAndroidPeripheral. NewPeripheralBuilder.mtudefaults to 517 (nullskips any MTU request); the library requests MTU after GATT connect and before service discovery.Breaking: public
AndroidPeripheral.requestMtuandServicesDiscoveredPeripheral.requestMtuare removed.connect()docs noteBLUETOOTH_CONNECTwhen MTU is non-null.maximumWriteValueLengthForTypeis capped by Android max attribute length (512 on API 33+, 600 on older APIs).Reviewed by Cursor Bugbot for commit bce7bae. Configure here.